Re: passwd hashing algorithm

John F. Haugh II (jfh@rpp386.cactus.org)
Fri, 21 Apr 95 12:00:02 CDT

> Yes, but your original message was not specific as to the resulting
> hash output.  Both David Wagner and I understood you to mean that the 
> resulting hash was still only 8 bytes.  This was the cause of the potential 
> security hole that he outlined that made an attack significantly easier than 
> searching a single 8 byte hash space.  The resulting exchange of messages 
> strongly implied that SecureWare's products contained such a security hole.  
> I was merely stating that our product does not contain this specific 
> security hole (or any other of which I am aware :-)).  Our implementation 
> is equivalent to serially searching N 8 byte password hash spaces where N 
> is the number of 8 byte blocks (not limited to two) in the password (except, 
> perhaps for the final block).  Of course, it would be even better if they 
> had to crack a single 8*N byte password hash space, but as has been pointed
> out several times to this list, this should best be done using a real hash
> function.

My replies have always been in the context of what Shadow does for long
passwords.  Yes, there has been some confusion in this thread.  I was, uh,
quite shocked to see what David Wagner was really talking about because
it is pretty obvious that it has security problems.  Essentially, it
removes the 1:1 cleartext to ciphertext relationship that some of us feel
crypt() has.  I don't know what the new relationship is, but its probably
GodAwfulLarge to 1.  Once you assume that there are GodAwfulMany passwords
which yield the same result, the 2^56 brute force attack is much easier.

I am very familiar with how SecureWare implements extended passwords
and the strength of them.  (Would you like to see a re-implemented version
of the source code? ;-) I do think it is a very nice way of chaining
crypt blocks together, but it is subject to suffix attacks the same as
Shadow and it is at most only 10 times more difficult to crack than
straight crypt() (and circa 5 times harder than DOUBLESIZE Shadow).  With
English words as the alphabet, each block is subject to common word suffix
and prefix attacks.  crypt() is seriously deficient, sad to say.

In the case of Shadow, I never intended longer passwords to do anything
but allow for people to use 8 to 10 (or 12 or so) character passwords with
all characters being significant, instead of lopping things off at 8 bytes.
MD5 is definitely looking to be a much better hash and there will be MD5
support imbedded in the next version of Shadow.
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org